(talking DOORS V8.2):
I know what the documentation says it can do but (unless I'm doing something wrong) the functionality seems rather limited.
Sets the value of the specified attribute based on the HTML in the buffer.
If the call succeeds, returns a null string; otherwise, returns an error message.
Based on the documentation, one can load a buffer with HTML text and call setAttrFromHTML() which will populate the specified object attribute with a rendering based on the supplied HTML.
In short I can get the help file example for bolding text to work but can't get a simple table to render.
For DOORS V8.2, does anyone know what HTML functionality (or subset) is supported by setAttrFromHTML()? Sorry, I was not too impressed by the bolding text example (there are simpler ways to do that). I was hoping for a bit more.
I attached a browser rendering of a very simple table. I was hoping the code below would insert something that resembled a table into o."Object Text". When the smoke clears all that is populated is the inner table text with no tabular formatting whatsoever.
void canDoors82InsertATwoRowTwoColumnTable() {
// Suppose the cursor on an object in a module open for write.
Buffer b = create();
string errorMessage;
Object o = (Object current);
Module m = (Module current);
print("The initial content of object " (o."Absolute Number") " is " (o."Object Text") "\n");
// This seems to work
b = "That was a <b>bold</b> move.";
errorMessage = setAttrFromHTML(b, o."Object Text");
if (!null(errorMessage)) {
ack("setAttrFromHTML failed: " errorMessage);
}
refresh(m);
ack "The word \"bold\" is bolded as expected."
// This does not fail but does not render a table as expected
b = "<table border=\"1\"><tr><td>Row1 Col1</td><td>Row1 Col2</td></tr><tr><td>Row2 Col1</td><td>Row2 Col2</td></tr></table>";
errorMessage = setAttrFromHTML(b, o."Object Text");
if (!null(errorMessage)) {
ack("setAttrFromHTML failed: " errorMessage);
}
refresh(m);
ack "Was expecting to see a table. Where is it?"
delete b;
}
canDoors82InsertATwoRowTwoColumnTable();
Can the code above be modified to produce the desired result?
Has anyone been down this road and can share what setAttrFromHTML() can or can not do?
Thanks in advance for comments.
SystemAdmin - Thu Sep 23 11:27:30 EDT 2010 |
|
Re: What can setAttrFromHTML() do? Mathias Mamsch - Fri Sep 24 18:09:13 EDT 2010
I guess you are out of luck there. I have no idea what kind of formatting telelogic chose to support, but I would not expect anything great. Open a Microsoft Word in the background, paste the HTML there. Copy it and paste it to the attribute. This will give you an RTF table. Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
|
|
Re: What can setAttrFromHTML() do? SystemAdmin - Fri Sep 24 18:37:17 EDT 2010 Mathias Mamsch - Fri Sep 24 18:09:13 EDT 2010
I guess you are out of luck there. I have no idea what kind of formatting telelogic chose to support, but I would not expect anything great. Open a Microsoft Word in the background, paste the HTML there. Copy it and paste it to the attribute. This will give you an RTF table. Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
Since HTML table syntax and encoding is much more well behaved and specified than RTF tables, I was hoping for a clean way to programatically create syntactically correct RTF tables that are a single DOORS object.
The goal is to occupy one DOORS row, but (1) look nice, (2) be able to filter them in and out like other DOORS objects, (3) be programmable via DXL because RTF tables are very fragile in the DOORS window and once users start attempting to change them ... (no need to go on.)
You can paste them in just fine but that is about it.
Straight RTF programming is realizable but ...
Like Yoda, "Great pain" (I feel).
|
|
Re: What can setAttrFromHTML() do? Mathias Mamsch - Sat Sep 25 13:05:41 EDT 2010 SystemAdmin - Fri Sep 24 18:37:17 EDT 2010
Since HTML table syntax and encoding is much more well behaved and specified than RTF tables, I was hoping for a clean way to programatically create syntactically correct RTF tables that are a single DOORS object.
The goal is to occupy one DOORS row, but (1) look nice, (2) be able to filter them in and out like other DOORS objects, (3) be programmable via DXL because RTF tables are very fragile in the DOORS window and once users start attempting to change them ... (no need to go on.)
You can paste them in just fine but that is about it.
Straight RTF programming is realizable but ...
Like Yoda, "Great pain" (I feel).
Yes the table thing is bad. Why do you want to have a table with one row? To link on it? Or to have additional columns for it.
I stumbled over it a few times, but do not have a nice solution. I tried some:
1) Putting a GUI in a sync trigger that will pop up a GUI for editing, when a table element (simple DOORS object) was found, that would allow the user to edit the table.
2) The same, but I used a DOORS table instead and the GUI allowed to edit the additional attributes of the table head.
3) Automatic Word or Excel conversion of DOORS tables (btw. you can still put the rtf of a word table into a DXL attribute to filter on it!)
Meanwhile I have come to the conclusion, that I will try to talk the customers out of wanting to use a table as some special kind of requirement and tell them, if a table is part of the requirement it should be referenced in the requirement.
I can feel your pain too. I guess the easiest resolution (like a lot of times with DOORS) is to lower your standards :-)
Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
|
|
Re: What can setAttrFromHTML() do? SystemAdmin - Mon Sep 27 12:44:18 EDT 2010 Mathias Mamsch - Sat Sep 25 13:05:41 EDT 2010
Yes the table thing is bad. Why do you want to have a table with one row? To link on it? Or to have additional columns for it.
I stumbled over it a few times, but do not have a nice solution. I tried some:
1) Putting a GUI in a sync trigger that will pop up a GUI for editing, when a table element (simple DOORS object) was found, that would allow the user to edit the table.
2) The same, but I used a DOORS table instead and the GUI allowed to edit the additional attributes of the table head.
3) Automatic Word or Excel conversion of DOORS tables (btw. you can still put the rtf of a word table into a DXL attribute to filter on it!)
Meanwhile I have come to the conclusion, that I will try to talk the customers out of wanting to use a table as some special kind of requirement and tell them, if a table is part of the requirement it should be referenced in the requirement.
I can feel your pain too. I guess the easiest resolution (like a lot of times with DOORS) is to lower your standards :-)
Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
The application of the desired single-DOORS-object RTF table rows would be to show a correlation that is most clearly shown in a table but where individual rows may be "filtered out" based on target need (e.g., specific customer).
A simple example is an acronym definition table. Some terms are general. Some terms are customer-specific. Some terms are "configuration-specific".
The filter part is easy (a column for each filterable attribute, e.g., customer, etc.)
The only challenge is choosing how to display the acronyms and their definitions in the main "Object Text" column.
If we saw an acronym definitions in a book, Word document, or HTML page, chances are very high it would be implemented as a table. This makes all the acronyms and definitions horizontally aligned.
REALIZING THIS IN DOORS (PROS/CONS of various techniques):
1) DOORS Table - Each cell is its own object so seeing its filter attributes is not easy to set and maintain. For example if one desires to make an acronym and its definition associated with a specific customer only, you have the make sure to set appropriate attributes for both the acronym DOORS cell and the Acronym Definition Cell (a nuisance to maintain and verify).
2) OLE Table - Overkill and text won't be search-able.
3) RTF Table Row - Works fine but DOORS GUI does not support an RTF table editor. The RTF table solution would be for each table row to be a unique DOORS object (that way it can be filtered in or out as a set). If each each RTF row is formatted the same (e.g., show borders, left cell is 1 inch, and right cell is 4 inch) than the objective is achieved.
4) Just do "ACC - ACC Definition" as plain old text
(Will work but definitions will have a ragged edge (left side is not aligned).
5) On each line do (like a properties entry):
-
Acronym = API
-
Definition = Application Program Interface
(Works but visually harder to spot terms)
Summarizing the desire is:
*** OBJECT TEXT ********* | *** CUSTOMER **** | *** Object No *** |
| ACRONYM | DEFINITION | All Customers | 1001 |
| ACC1 | Definition 1 | All Customers | 1002 |
| ACC2 | Definition 2 | All Customers | 1003 |
| ACC3 | Definition 3 | Customer A | 1004 |
| ACC4 | Definition 4 | All Customers | 1005 |
| ACC5 | Definition 5 | Customer B | 1006 |
For the above, if we were to apply a filter for "All Customers" and "Customer B" we would expect to see a table with all rows shown except Object 1004.
// *** More knarly than HTML, but works in DOORS 8.2
void loadAcronymToObjectText(Object o,
string acronym,
string meaning) {
Module m = (Module current);
Buffer b = create();
b += "{\\rtf1\\ansi\\ansicpg1252\\deff0\\deflang1033\\deflangfe1033";
b += "\\trowd\\trgaph108\\trleft-108\\trbrdrl\\brdrs\\brdrw10";
b += "\\trbrdrt\\brdrs\\brdrw10 \\trbrdrr\\brdrs\\brdrw10";
b += "\\trbrdrb\\brdrs\\brdrw10 \\trpaddl108\\trpaddr108\\trpaddfl3\\trpaddfr3";
b += "\\clbrdrl\\brdrw10\\brdrs\\clbrdrt\\brdrw10\\brdrs\\clbrdrr\\brdrw10\\brdrs\\clbrdrb\\brdrw10\\brdrs";
b += "\\cellx1440\\clbrdrl\\brdrw10\\brdrs\\clbrdrt\\brdrw10\\brdrs\\clbrdrr\\brdrw10\\brdrs\\clbrdrb\\brdrw10\\brdrs";
b += "\\cellx6748\\pard\\intbl "
b += acronym;
b += "\\cell ";
b += meaning;
b += "\\cell\\row\\pard}";
o."Object Text" = richText(tempStringOf(b));
refresh(m);
delete b;
}
See attached picture for DOORS rendering.
Attachments
attachment_14536110_rtfTableRow.jpg
|
|
Re: What can setAttrFromHTML() do? Mathias Mamsch - Mon Sep 27 14:59:01 EDT 2010 SystemAdmin - Mon Sep 27 12:44:18 EDT 2010
The application of the desired single-DOORS-object RTF table rows would be to show a correlation that is most clearly shown in a table but where individual rows may be "filtered out" based on target need (e.g., specific customer).
A simple example is an acronym definition table. Some terms are general. Some terms are customer-specific. Some terms are "configuration-specific".
The filter part is easy (a column for each filterable attribute, e.g., customer, etc.)
The only challenge is choosing how to display the acronyms and their definitions in the main "Object Text" column.
If we saw an acronym definitions in a book, Word document, or HTML page, chances are very high it would be implemented as a table. This makes all the acronyms and definitions horizontally aligned.
REALIZING THIS IN DOORS (PROS/CONS of various techniques):
1) DOORS Table - Each cell is its own object so seeing its filter attributes is not easy to set and maintain. For example if one desires to make an acronym and its definition associated with a specific customer only, you have the make sure to set appropriate attributes for both the acronym DOORS cell and the Acronym Definition Cell (a nuisance to maintain and verify).
2) OLE Table - Overkill and text won't be search-able.
3) RTF Table Row - Works fine but DOORS GUI does not support an RTF table editor. The RTF table solution would be for each table row to be a unique DOORS object (that way it can be filtered in or out as a set). If each each RTF row is formatted the same (e.g., show borders, left cell is 1 inch, and right cell is 4 inch) than the objective is achieved.
4) Just do "ACC - ACC Definition" as plain old text
(Will work but definitions will have a ragged edge (left side is not aligned).
5) On each line do (like a properties entry):
-
Acronym = API
-
Definition = Application Program Interface
(Works but visually harder to spot terms)
Summarizing the desire is:
*** OBJECT TEXT ********* | *** CUSTOMER **** | *** Object No *** |
| ACRONYM | DEFINITION | All Customers | 1001 |
| ACC1 | Definition 1 | All Customers | 1002 |
| ACC2 | Definition 2 | All Customers | 1003 |
| ACC3 | Definition 3 | Customer A | 1004 |
| ACC4 | Definition 4 | All Customers | 1005 |
| ACC5 | Definition 5 | Customer B | 1006 |
For the above, if we were to apply a filter for "All Customers" and "Customer B" we would expect to see a table with all rows shown except Object 1004.
// *** More knarly than HTML, but works in DOORS 8.2
void loadAcronymToObjectText(Object o,
string acronym,
string meaning) {
Module m = (Module current);
Buffer b = create();
b += "{\\rtf1\\ansi\\ansicpg1252\\deff0\\deflang1033\\deflangfe1033";
b += "\\trowd\\trgaph108\\trleft-108\\trbrdrl\\brdrs\\brdrw10";
b += "\\trbrdrt\\brdrs\\brdrw10 \\trbrdrr\\brdrs\\brdrw10";
b += "\\trbrdrb\\brdrs\\brdrw10 \\trpaddl108\\trpaddr108\\trpaddfl3\\trpaddfr3";
b += "\\clbrdrl\\brdrw10\\brdrs\\clbrdrt\\brdrw10\\brdrs\\clbrdrr\\brdrw10\\brdrs\\clbrdrb\\brdrw10\\brdrs";
b += "\\cellx1440\\clbrdrl\\brdrw10\\brdrs\\clbrdrt\\brdrw10\\brdrs\\clbrdrr\\brdrw10\\brdrs\\clbrdrb\\brdrw10\\brdrs";
b += "\\cellx6748\\pard\\intbl "
b += acronym;
b += "\\cell ";
b += meaning;
b += "\\cell\\row\\pard}";
o."Object Text" = richText(tempStringOf(b));
refresh(m);
delete b;
}
See attached picture for DOORS rendering.
For your requirement I would go with DOORS tables. I would define an object attribute (Manual Customer, Enumeration -> customers) and a DXL attribute "Customer(s)".
The DXL attribute would:
-
if obj is a normal object return the "Manual Customer"
-
if obj is a table cell, then 1. check if the table has a "Customer Column" (look for a special title), 2. for every cell in a column that is not the customer column, return the value of the customer column (if it exists, otherwise nothing) 3. for every cell of the customer column return something special like "<customer column>"
This way the user can edit the customer in a column of the table (very comfortable). You can filter the complete table and all objects regarding to the customer attribute (how cool is that). You can hide the customer columns of tables only (by filtering on the special value "<customer column"> (good for exports).
Then you might install a trigger that will update the DXL attribute, when the user edits an object, so that the experience will be complete.
What do you think??
Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
|
|
Re: What can setAttrFromHTML() do? SystemAdmin - Mon Sep 27 16:17:01 EDT 2010 Mathias Mamsch - Mon Sep 27 14:59:01 EDT 2010
For your requirement I would go with DOORS tables. I would define an object attribute (Manual Customer, Enumeration -> customers) and a DXL attribute "Customer(s)".
The DXL attribute would:
-
if obj is a normal object return the "Manual Customer"
-
if obj is a table cell, then 1. check if the table has a "Customer Column" (look for a special title), 2. for every cell in a column that is not the customer column, return the value of the customer column (if it exists, otherwise nothing) 3. for every cell of the customer column return something special like "<customer column>"
This way the user can edit the customer in a column of the table (very comfortable). You can filter the complete table and all objects regarding to the customer attribute (how cool is that). You can hide the customer columns of tables only (by filtering on the special value "<customer column"> (good for exports).
Then you might install a trigger that will update the DXL attribute, when the user edits an object, so that the experience will be complete.
What do you think??
Regards, Mathias
Mathias Mamsch, IT-QBase GmbH, Consultant for Requirement Engineering and D00RS
Thanks for the idea. I may need a Paulaner Oktoberfest Märzen (or two) before diving in.
|
|